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Remarks 

The above Amendments and these Remarks are in reply to the Office Action mailed April 
12, 2006. A Petition for Extension of Time is submitted herewith, together with the appropriate fee. 

I. Summary of Examiner's Rejections 

Prior to the Office Action mailed April 12, 2006, Claims 1 , 2, 4-12, 14-20, 22-24, 28, 30, 31 
and 34-39 were pending in the Application. In the Office Action, Claims 1 , 2, 4, 5, 7, 11, 12, 14, 
15, 17 and 22-33 were rejected under 35 U.S.C. 103(a) as being unpatentable over Meltzer et al. 
(U.S. Patent No. 6,226,675, hereafter Meltzer) in view of Kuznetsov (U.S. Patent No. 6,772,41 3). 
Claims 6, 8, 9, 16, 18 and 19 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Meltzer in view of Borwankar (U.S. Patent No. 6,594,693). Claims 10 and 20 were rejected under 
35 U.S.C. 103(a) as being unpatentable over Meltzer and Borwankar, in further view of Pinard et 
al. (U.S. Patent No. 6,230,287, hereafter Pinard). Claims 34-39 were rejected under 35 U.S.C. 
103(a) as being unpatentable over Meltzer and Kuznetsov, in further view of Burridge (U.S. Patent 
No. 6,446,116). 

II. Summary of Applicant's Amendment 

The present Response amends Claims 1 , 1 1 , 38 and 39, leaving for the Examiner's present 
consideration Claims 1, 2, 4-12, 14-20, 22-24, 28, 30, 31 and 34-39. Reconsideration of the 
Application, as amended, is respectfully requested. Applicant respectfully reserves the right to 
prosecute any originally presented claims or canceled claims in a continuing or future application. 

III. Claim Rejections under 35 U.S.C. §1 03(a) 

In the Office Action mailed April 12, 2006, Claims 1 and 1 1 were rejected under 35 U.S.C. 
103(a) as being unpatentable over Meltzer (U.S. Patent No. 6,226,675) in view of Kuznetsov (U.S. 
Patent No. 6,772,413). 
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Claim 1 

Claim 1 has been amended by the current Response to more clearly define the embodiment 
therein. As amended, Claim 1 defines: 

1. (Currently Amended) A conversation manager executing on an intermediate 
collaboration server for managing the flow of messages in a collaboration system, 
comprising: 

a conversation initiation logic that initiates a conversation among a plurality of 
participants, wherein said conversation is a collective set of messages exchanged by the 
plurality of participants according to an extensible protocol; 

a participation registration logic that registers said participants in said conversation; 

a conversation repository that stores conversation management data used to 
manage said conversation among said plurality of participants; 

a plurality of business protocol handlers, each of which are configured to recognize 
a different business protocol vocabulary, and which may be used by a participant to send 
and to receive messages according to the particular business protocol vocabulary and 
process flow used by that participant; 

a plurality of decoders that receive incoming messages from senders, identify 
protocol-specific headers in the incoming messages and assign the incoming messages to 
an appropriate business protocol handler; 

a plurality of encoders that send outgoing messages to recipients, including 
assigning the outgoing messages to an appropriate business protocol handler that matches 
the business protocol vocabulary of the recipients; and 

a transport configured to accept messages from the participants using any of the 
different business protocols, identify the business protocol being used, and invoke one or 
more of said plurality of decoders and encoders to communicate the messages between 
a first participant using a first business protocol vocabulary, and a plurality other participants 
using different business protocol vocabularies. 

Claim 1, as currently amended, defines that the conversation manager comprises a plurality 
of business protocol handlers, each of which are configured to recognize a different business 
protocol vocabulary, and which may be used by a participant to send and to receive messages 
according to the particular business protocol vocabulary and process flow used by that participant. 
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A plurality of decoders receive incoming messages from senders, identify protocol-specific headers 
in the incoming messages and assign the incoming messages to an appropriate business protocol 
handler. A plurality of encoders send outgoing messages to recipients, including assigning the 
outgoing messages to an appropriate business protocol handlerthat matches the business protocol 
vocabulary of the recipients. The conversation manager further comprises a transport configured 
to accept messages from the participants using any of the different business protocols, identify the 
business protocol being used, and invoke one or more of said plurality of decoders and encoders 
to communicate the messages between a first participant using a first business protocol 
vocabulary, and a plurality other participants using different business protocol vocabularies. 

The advantages of the embodiment currently defined by Claim 1 include that it is 
independent of any particular business protocol vocabulary, so it can support any standards-based 
or proprietary business protocol or business protocol vocabulary. For example, one participant may 
use a RosettaNet business protocol vocabulary, while another participant may use an EDI 
business protocol vocabulary. By providing a plurality of business protocol handlers, the system 
allows for conversational communication between these collaboration participants that utilize 
different business protocols. This translation can be extended beyond the simple case of two 
participants having different protocols: instead a first participant (sender) can send messages using 
a first business protocol vocabulary, and a plurality other participants (recipients) can each use their 
own different business protocol vocabularies to receive the message. In the embodiment defined 
by Claim 1, this functionality is provided by a plurality of decoders that receive the incoming 
messages from senders, and assign the incoming messages to an appropriate business protocol 
handler; together with a plurality of encoders that send the outgoing messages to recipients, 
including assigning the outgoing messages to an appropriate business protocol handler that 
matches the business protocol vocabulary of the recipients. 

Meltzer discloses a participant server which processes documents for commerce in trading 
partner networks. As disclosed by Meltzer, business interface definitions (BIDs), which describe 
the documents to be exchanged, are communicated to members of the network. The business 
interface definitions tell potential trading partners the services the company offers and the 
documents to use when communicating with such services. (Column 2, lines 34-48). A participant 
node includes resources for translating at least a portion of the input document into a format 
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readable according to the variant transaction processing architecture of the transaction process 
utilizing the information. (Column 5, lines 1-5). 

Kuznetsov discloses a flexible transformation mechanism that facilitates generation of 
translation machine code on the fly. As disclosed by Kuznetsov, a stream of data arrives from an 
external source, such as an application server, and the headers and other selected fields are 
separated and processed to detect source and destination identification information, along with the 
data format and the protocol being used. At the lowest protocol levels, a unique address or other 
identification will suffice for identification, such as the combination of an IP address and a socket 
corresponding to a communication channel. (Column 9, line 58 - Column 10, line 5). One or more 
FMRFD parsers provide inputs to a DATADEF source interface and one or more DMAP parsers 
provide inputs to a DATAMAP source interface. The parsers can be selected as appropriate for 
parsing FMRFD inputs provided as C/C++ Headers, ASN.1 formats, IDL, or other standard or 
proprietary parsers can be adapted to generate the required DATADEF from the corresponding 
FMRFD formats. (Column 12, line 63 - Column 13, line 18). 

Applicant respectfully submits that, as described above, Meltzer appears to disclose a 
system in which a participant communicates with another participant (or a group of participants) 
by a first (sending) participant sending a document that conforms to the specification or BID of a 
second (receiving) participant. The business interface definitions tell potential trading partners 
which services a participant offers, and which documents to use when communicating with such 
services. This process is different from the embodiment defined by Claim 1 , wherein a participant 
is free to use any business protocol supported by the collaboration server, and is not restricted to 
conforming to the protocol of the receiving partner. Claim 1 has also been amended to more 
clearly define the system as comprising a plurality of decoders that receive incoming messages 
from senders, identify protocol-specific headers in the incoming messages and assign the incoming 
messages to an appropriate business protocol handler; and a plurality of encoders that send 
outgoing messages to recipients, including assigning the outgoing messages to an appropriate 
business protocol handler that matches the business protocol vocabulary of the recipients. Thus, 
whereas in Meltzer the BID definition allows a customer to place an order compliant with a 
document definition published in the BID of another party; in accordance with the embodiment of 
Claim 1, a sending participant is not required to be compliant with a recipient's specification, and 
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indeed a sending party can send messages in it's own business protocol vocabulary, and have 
those messages translated into a variety of different business protocols corresponding to each of 
the recipients. 

With regard to the Kuznetsov reference, Applicant respectfully submits that, as described 
above, Kuznetsov appears to describe a means of processing program language (for example 
C/C++ headers) headers which are contained in the stream of data. Formal machine readable 
format descriptions can be defined for each data format and/or network protocol to describe the 
structural layout of the packets or data streams or other data structures being translated. Applicant 
respectfully submits that Kuznetsov appears to describe a means of translating between network 
protocols, but does not appear to disclose an extensible business protocol that is independent of 
the network protocol. As such, the network protocols and data formats described in Kusnetsov 
differ substantially from the B2B business protocols that are the subject of Claim 1, examples of 
which include cXML, BizTalk, and RosettaNet. To more clearly differentiate this, Claim 1 has been 
amended to define that each of the plurality of business protocol handlers are configured to 
recognize a different business protocol vocabulary, and may be used by a participant to send and 
receive messages according to the particular business protocol vocabulary and process flow used 
by that participant. 

In view of the above comments, Applicant respectfully submits that Claim 1 is neither 
anticipated by, nor obvious in view of the cited references, and reconsideration thereof is 
respectfully requested. 

Claim 11 

Claim 1 1 has been amended similarly to Claim 1 to more clearly define the embodiment 
therein. Applicant respectfully submits that Claim 1 1 , as amended, is likewise neither anticipated 
by, nor obvious in view of the cited references, and reconsideration thereof is respectfully 
requested. 
Claims 38 and 39 

In the Office Action mailed April 1 2, 2006, Claims 38 and 39 were rejected under 35 U.S.C. 
1 03(a) as being unpatentable over Meltzer (U.S. Patent No. 6,226,675) and Kuznetsov (U.S. Patent 
No. 6,772,413), in further view of Burridge (U.S. Patent No. 6,446,116). 
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Burridge discloses a method and apparatus for dynamically loading a transport mechanism 
in a multipoint data delivery system. A multi-point data delivery system provides a communication 
mechanism between users or a computer system which permits sending messages point to point, 
and point to multiple points. A resource locator (RL) corresponding to a collaboration session is 
requested from a registry. A location indicator of the RL in the registry is received from the registry. 
In response to receiving the location indicator of the RL in the registry, a transportation mechanism 
specified in the RL is dynamically loaded, and the collaboration session is joined. The 
transportation mechanism is a protocol stack identifying the transportation protocol used. The 
transportation protocols may include transmission control protocol (TCP), user datagrams protocol 
(UDP), remote method invocation (RMI), T.120, Common Object Request Broker Architecture 
(CORBA), Scaleable Reliable Multicast (SRM), and other transportation level implementations. 
(Column 1, line 55 - Column 2, line 7). 

It appears from the above description that the network and transportation protocols 
described in Burridge differ substantially from the B2B business protocols that are the subject of 
Claims 38 and 39. As described above examples of business protocols include cXML, BizTalk, and 
RosettaNet. To more clearly differentiate this, Claims 38 and 39 have been amended to define 
that each of the plurality of business protocol handlers are configured to recognize a different 
business protocol vocabulary, and may be used by a participant to send and receive messages 
according to the particular business protocol vocabulary and process flow used by that participant. 

In view of the above comments, Applicant respectfully submits that Claims 38 and 39 are 
neither anticipated by, nor obvious in view of the cited references, and reconsideration thereof is 
respectfully requested. 

Claims 2, 4-10, 12, 14-20, 22-24, 28, 30, 31 and 34-37 

In the Office Action mailed April 12, 2006, Claims 2, 4, 5, 7, 12, 14, 15, 17 and 22-33 were 
rejected under 35 U.S.C. 103(a) as being unpatentable over Meltzer (U.S. Patent No. 6,226,675) 
in view of Kuznetsov (U.S. Patent No. 6,772,413). Claims 6, 8, 9, 16, 18 and 19 were rejected 
under 35 U.S.C. 1 03(a) as being unpatentable over Meltzer in view of Borwankar (U.S. Patent No. 
6,594,693). Claims 10 and 20 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Meltzer and Borwankar, in further view of Pinard (U.S. Patent No. 6,230,287). Claims 34-37 were 
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rejected under 35 U.S.C. 103(a) as being unpatentable over Meltzer and Kuznetsov, in further view 
of Burridge (U.S. Patent No. 6,446,116). 

The above-referenced claims are not addressed separately, but it is respectfully submitted 
that these claims are allowable as depending from an allowable independent claim, and further in 
view of the current amendments to the independent claims, and the comments provided above. 
Applicant respectfully submits that Claims 2, 4-10, 12, 14-20, 22-24, 28, 30, 31 and 34-37 are 
similarly neither anticipated by, nor obvious in view of the cited references, and reconsideration 
thereof is respectfully requested. 

IV. Conclusion 

In view of the above amendments and remarks, it is respectfully submitted that all of the 
claims now pending in the subject patent application should be allowable, and reconsideration 
thereof is respectfully requested. The Examiner is respectfully requested to telephone the 
undersigned if he can assist in any way in expediting issuance of a patent. 

Enclosed is a PETITION FOR EXTENSION OF TIME UNDER 37 C.F.R. §1.136 for 
extending the time to respond up to and including October 12, 2006. 

The Commissioner is authorized to charge any underpayment or credit any overpayment 
to Deposit Account No. 06-1 325 for any matter in connection with this response, including any fee 
for extension of time, which may be required. 

Respectfully submitted, 

Date: By: /Karl F. Kenna/ 

Karl F. Kenna 
Reg. No. 45,445 

Customer No.: 23910 

FLIESLER MEYER LLP 

Four Embarcadero Center, Fourth Floor 

San Francisco, California 94111-4156 

Telephone: (415) 362-3800 
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